产业调研：恒生电子纳秒级交易系统踏上性能之巅

产业调研系列

核心要点

1、对机构交易来说，时间就是金钱，所以对延迟的要求是逐步不停地在提升，可以说是永无止境。

2、交易系统延迟主要包括网络延迟、锁延迟、陷入内核、线程切换。

3、恒生电子以FPGA开发框架为基础，实现了软硬件结合的分布式架构。在FPGA上面，每个主机可以做一个软硬分离，硬件部分在硬件做，然后复杂逻辑穿透PCIE到达软件部分，再通过FPGA网口和另外一个FPGA进行交互，这样的话达到FPGA突破的多点化部署，以实现一个分布式部署。

01.背景

机构交易对于低延迟要求不断提升。在金融证券领域机构交易的占比逐年在提升，之前我们在金融证券领域的所谓的高性能一般来说都是指高吞吐量，追求的都是在满足一定延迟要求下的高吞吐量。但是随着机构交易的占比逐渐提升，对机构交易来说，时间就是金钱，所以对延迟的要求是逐步不停地在提升，可以说是永无止境。由此也导致了对券商来说就是新一轮的军备竞赛——谁能够在延迟上取得最低的延迟，谁就可以掌握客户。

去IOE和去数据库的要求浮出水面。并且还有一个是去 IOE 的要求。实际上目前不只是去 IOE 的要求，可能还会存在一个去数据库的要求。因为随着一个极致的低延迟需求的提出，实际上去数据库、全内存化的交易可能就是趋势。

02.影响性能的要素

对一个已经比较合理设计的，并且算法上也已经过优化的去数据库的内存系统来说，影响延迟的因素有哪些呢？

我们这里总结了一下，基本上可能也是可以从用户有感的角度出发排了个序。

第一个是网络通信。网络通信一般来说是整个全链路交易延迟当中的大头，可能占了百分之五六十以上的延迟。

另外一个是业务逻辑处理当中不可避免的会存在一些锁的操作。锁的时间开销取决于这个锁的类型以及锁的粒度，它的延迟有可能是纳秒级，有可能是微秒级，但是对一个设计不当的系统来说，甚至可以到达毫秒级。

再一个是我们要尽量的避免陷入内核。因为每一次陷入内核，它都是一个近乎微秒级的延迟。而我们现在在这里讲的性能都是全链路交易延迟，是要达到个位数的微秒级，所以每一次陷入内核对我们来说就是一个灾难。

再一个是要尽量的避免线程切换。因为线程切换实际上也是有陷入内核的，并且它还会有一个上下文的切换，这个开销是蛮大的。

除去前面的这些，后面实际上是一些我们可能会比较忽略的，就是一个申请内存的访问，这个延迟可能它也是不等的。

因为我刚才讲的网络延迟是一个大头，我大概来分析一下网络延迟的一个开销。网络延迟实际上我们又可以把它分为三部分，一部分是传输延迟。传输延迟，就是说我把报文放到介质上所需要的时间，那个是受限于带宽。还有一个是传播延迟，就是从 A地传输到 B地所花费的一个时间。再一个是在中间可能会有经过各种网络设备的一个交换延迟。

这里我们可以举个例，假设是个千兆带宽，100个字节，传输 1000 公里，那这里边传输延迟大概就是在 1微秒左右。然后传播延迟会达到几个毫秒，大概是 4、5 毫秒。交换延迟就视中间的交换设备而定，每增加一个交换设备，那理论上就增加1微秒左右的一个延迟。

但是这里面的传输延迟1微秒其实是一个很理想化的数字。因为我们这里面已经忽略了协议栈的处理延迟，其实这里面协议栈的处理延迟是一个大头。那么如何避免这个协议栈的处理延迟？这里面可能就涉及到一个Kernel Bypass技术。

再一个是锁。对锁来说，实际上一方面我们要考虑的是锁的固有延迟开销。然后锁的类型比如说有读写锁、互斥锁、自旋锁，那这里面锁的固有延迟开销，自旋锁是最低的，它可能是只有几个纳秒，也就是说几个时钟周期。互斥锁是其次，读写锁的固有开销是最大的。

但是我们不能够只考虑它的固有延迟开销，我们可能还需要考虑到它的争用的频度、锁的粒度。如果结合业务的上下文来考虑的时候，我们会发现哪怕我们用的是自旋锁，因为自旋锁只有几纳秒的一个延迟开销，成本是最低的。但是如果考虑到我们的业务逻辑，锁的粒度如果比较粗，并且它的争用频度比较高。那么如果我们使用了一个自旋锁，可能对整个系统来说是一场灾难，大量的 CPU 都消耗在无谓的等待这把自旋锁。再一个我们要考虑到如果加了锁，实际上一般来说是会增加一个线程切换的。

03.瓶颈定位

然后我们的系统已经达到了一定的瓶颈，如何来根据当前系统的表现，我们观察上的一些现象，来大概判断出瓶颈大概在哪里？

一般来说我们可以从这几方面来判断。一个就是还是从网络带宽来判断，因为网络肯定是个最大的瓶颈。再一个，对于一个可能实现不是很优的系统来说，可能还会有个磁盘I/O。之所以前面没有把磁盘I/O列上去，是因为在我们做微秒级应用，一般来说不太会去考虑磁盘I/O。因为如果你有了磁盘I/O， 你这个性能估计就会不达标。所以我前面没有把它放上去，如果有了大量的磁盘I/O，那整个系统肯定是不能够达标的。再一个是我们来看当前的 CPU 的利用率是怎样的，根据 CPU 利用率大概的来做一下判断。

有了前面这些表象的判断之后，我们再来分析我们自己内部的应用实现当中，我们的线程亲缘性是怎样的？我们是怎样来使用我们的内存的？我们大概需要多少的内存？这个内存的数据结构、表达形式是怎样的？从这方面来考虑、来分析大概的瓶颈。

比如说我们从带宽上来说，一般来说我们追求的是低延迟，并且我们要追求大吞吐量。那要追求大吞吐量，必然我们的网络带宽我们希望越高越好，否则就说明我们的吞吐量上不去。但是当网络带宽高的时候，其实我们的单笔延迟势必是受影响的，必然会对单笔延迟会有一定的冲击。

还有一个是我们追求的是能够使得网络带宽能够挡上去，但是网络带宽挡上去的时候，真的吞吐量上升了吗？其实是要打个问号的。因为这里面我们就要关心这个带宽流量是有效载荷还是无效载荷，这里边的有效无效的一个比例大概是怎样。

一方面，有可能这里面的带宽都是由于大量的重传导致的，因为我们自己对延迟要求比较高，可能会有一个在比较短的时间之内就会有一个重传。那么实际上是不是这里面大量的重传导致了带宽的上升？

还有一个是我们的应用层协议是不是设计合理的，是不是有效数据在整个的报文当中占比过小？那如果是这样子，那么是不是可以通过压缩来提升性能？那这里面要评估的是，因为我的压缩是需要消耗 CPU 的，在 CPU 的消耗和网络流量降低之间，这两个能不能取得一个收益的平衡？

那么如果说是当我的网络小于，一般比较小的和比较好的值是达到一个百分之五六十，那一般会认为可能单笔延迟是可以得到保障的，因为网络不忙，整体不忙。但实际上我们所看到的，很多的监控工具、运维分析工具所看到的网络带宽只有百分之五六十，并且是一条水平的，感觉是整个表现都很好，没有高峰也没有低谷。

但实际上我们这个时候也还要问一下自己，因为我们追求的是微秒级，这是真实的现状吗？因为有可能这里面会涉及到网络未报的产生，就是说在某个极短的时间之内，我们的网络流量其实是有个突破的尖峰的，只是我们的运维没有观测到。

然后还有一个是我们来看 CPU。那对于低延迟，一般来说，当我们的系统达到瓶颈的时候，我们总能够看到CPU是有一个高峰的。但是这里面的高峰我们就要考虑到，对于多核系统来说，是所有的核都忙了，还是说只忙了仅仅几个核？然后在所有的核都忙的情况下，那这里边是不是我的工作不停地在每个核之间做切换，也就是说不能够达到CPU的线程亲缘性，突破了它的亲缘性会导致很大的问题，后面我们会讲到。

再一个是如果说CPU忙，它是真的忙了吗？就是说他忙是在做有效的业务吗？还是实际上是内耗掉了？就是因为我的线程太多，我线程切换太多，实际上他在做大量的系统的切换，而CPU不是在为我们业务干活，而是在为他自己内部的一些切换内耗掉了。

那刚才讲到是不是在做大量的线程切换？那这里面其实也就牵扯到一个问题，就是做内存访问的一个特性。内存访问，寄存器的访问一般，因为它是跟 CPU 周期数相等，那么我们认为是小于纳秒级，小于 1 纳秒。然后第一个一级缓存，它是1纳秒，二级10纳秒，三级在20纳秒，主存大概是在50纳秒。这样子的一个性能指标。

然后我们再考虑到NUMA架构，如果说是一个远端内存，那肯定还要在50 纳秒之上再加个几十纳秒，会达到百纳秒这个级别。那么线程亲缘性就是在利用局部性原理来增加它的一个缓存命中率，尽可能使得内存访问都在使用寄存器和一二级缓存，而不要每次都去做一个真实的内存访问。

那除去刚才的缓存亲缘性这个之外，可能还会有一个就是我们所谓的TLB颠簸。因为当我如果说我的工作集，前面也有一点就是我的工作集大小，工作集内存越大，那么所需要使用的页表就越多，但是页表它也是需要被寻址的，这个资源是受限的。如果说页表本身需要再次被寻址，那这里面就会有个 TLB 动作，那他的寻址的周期数时间延迟可能就会达到几十微秒甚至于到毫秒级。

04.性能评估

有了前面的那些性能上面的数据之后，我们再来看一下怎么来对系统做一个大概的性能评估。

首先根据带宽以及传输的路径和中间所经过的网络设备，就是整个的网络拓扑图，大概可以预估出网络延迟大概是多少。再一个根据这个磁盘I/O，也就是尽量避免磁盘I/O，但是一般来说会有一些紧急性的日志之类的。那这里面我要来评估一下，大概来做一个持久化，它的一个I/O 延迟会是多少？但是一般来说，这个磁盘I/O都是易补的，所以基本上是可以忽略的。

再一个是我根据自己业务的特性，数据结构，需要进行一笔完整的业务，它的工作集大小是多少。这个时候我大概可以再根据缓存的大小，自己主机缓存的大小和工作集的大小，大概可以评估出应该具备的合理的缓存命中率是多少？那么有了这个缓存命中率和工作集大小，大概就可以评估出内存访问的时间应该是多少。然后根据这些之后，就可以找到在全链路上延迟最大的瓶颈在哪里，并且合理的全链路延迟大概是多少，可以大致的给出这么一个数据。

这里面给了一个案例，这是一个通信延迟的一个计算。其实对一个最简单的一个 echo 服务，客户端到服务端的一个 echo 服务，客户端发送一个数据，服务端回送一个数据，这是一个最简单的案例。那在这里边，一般来说可能我们会觉得这里面没有什么花头可以操作的，实际上这里面把它的线程模型拆解成三种形式。

第一种是最简单的，客户端跟服务端大家都是一个线上。服务端一直都是一个线上不动，然后客户端的线程模型变一下，变成这三种模型。然后我们会发现这里面的数据就是整个的延迟差异是相当大的。最慢的是第一种，线程模型1，这个延迟是最慢的，它的 RTT 会达到四五微秒左右。然后最快的应该是线程模型2，这是最快的，大概会在三微秒左右。就是说好的跟差的大概能达到有个接近两微秒的性能差异。

我刚才也讲了可能被我们忽略掉的一个延迟的大头是在于内存访问，要对内存访问做一个严格的规划。但是我们一般在做开发的时候，大家都会觉得内存是个很快的，因为我们的直觉也告诉我们内存访问是很快的。那我们怎么来真正获得一个内存访问的延迟呢？我们觉得内存很快是因为实际上我们的内存访问的延迟绝大部分都被系统给隐藏掉了，一部分是 OS， 一部分是硬件层，都被隐藏掉了。那我们这边通过一个测试案例来获得一个真正的内存访问。就通过这样子的我根据一个步长，每间隔一个步长来访问一个字节，然后回过头来把整个4G全部访问完，和我顺序访问他的时间差距相当大，这里边的数据我不给了。

后面还有一个案例是矩阵访问的一个案例，矩阵乘法的案例。一般的传统的矩阵乘法就是我这张图里边的左边部分， A 乘 B 获得一个 C 。那这样子的一个矩阵乘，它实际上是突破了局部性原理，破坏了局部性原理。然后我把它转换成先把 B 做转置，然后 A 跟 B 的转置做这样一个另外一种模式的乘，这样子它就很好地利用了局部性原理。我们可以看它的一个时间性能，随着你矩阵的增加，他这两种的一个性能差距是很明显的，到最后能够有一个数量级的提升。当然这只是一个最简单的一块，实际上还可以再做更进一步的优化，更好地利用他的一个局部性原理。

05.案例分享

这是我们的一个案例：左边是我们未经优化的一个性能案例，右边是经过优化的。左边这里面它的平均延迟大概在1.8微秒，右边它的平均延迟大概在1.7微秒，并且最关键的是左边其实有大量的毛刺，右边没有毛刺了。那实际上这里边的毛刺产生就来自于主要是在内存，这里面的是在内存访问上的一个缺页操作造成的。那我们当时为什么能够把它分析出来，主要是基于针对这个毛刺间隔的一个规律性的统计，因为他有一个128跟512的间隔，就是很规律。那么我们根据这个，因为大概一个页表我们用的是 4k 的，那么可以分析下来大概是8个字节或者32字节的数据结构，我们在这上面的处理可能存在瑕疵。

然后根据这个假设，再去翻我们的代码。确实就是说在内存分配上，一开始其实只是分配了一个虚拟地址，而没有把它转换成一个物理地址。

06.挑战与展望

从软件层面来说，实际上性能到了极致之后，内存访问的瓶颈最终是不可消除的，除非材料科学的突破，否则内存访问延迟是不可能降低的。另外一个在后摩尔时代，实际上 CPU 主频的发展其实已经跟不上我们业务对延迟需求的发展了。再一个是，其实这样下去，大家各厂商的性能趋势是趋于雷同的。

所以我们可以发现，为了追求极致的低延迟，都有一个单体式应用的趋势。这实际上是在反分布式这个趋势的。那这里面我们为什么会有这个单体式应用，就是因为网络通信所造成的——每增加一个节点，总是要增加几个微秒的延迟，这对于低延迟来说是不可承受的。但是如果说我们利用 FPGA、利用硬件。这是我们对FPGA的一些性能数据的统计。如果说我用了FPGA，实际上我中间每加入一个节点，它的延迟大概也就在160纳秒左右，而160 纳秒其实已经跟本地内存访问相差无几了。那么有了这个基础之后，我就完全可以软件和硬件结合。

以下就是我们的新的一个构思图，也是我们现在正在做的。

一方面，我们有一个FPGA的开发平台。那么在FPGA上面，本身每个主机上面可以做一个软硬分离，硬件部分在硬件做，然后复杂逻辑穿透PCIE到达软件部分，再通过FPGA网口和另外一个FPGA进行交互，这样的话达到一个 FPGA突破的多点化部署，以实现一个分布式部署，同时又兼具低延迟的特性。这是我们我们当前的最新进展。

合规声明：本文节选自2022全球软件质量&效能大会纪要，属于公开资料，如需纪要全文请后台留言。

  - end -  

欢迎加入产业交流群！

欢迎所有对计算机产业研究和投资感兴趣的盆友（包括云计算、网络安全、医疗IT、金融科技、人工智能、自动驾驶等）后台留言加入我们的产业交流群。我们的目标是建立系统的计算机产业研究框架，提高整个A股的IT行业研究水平，减少韭菜数量，普度众生。